Development/secure socket port #1795
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rt server. Sofar Thunder supported SecureSocket clients where the intiative to enable secure connections was only based on creating a socket as a client. Tests are being written that require a secure socket server. This requires a sifferent set of calls and revealed an issue in the SocketPort. The server accepts the incoming socket. The bug was that the incoming socket, as it is already open and connected would not call the "Initialize()" method before it was added to the Resource Monitor. This has been fixed in SocketPort.cpp. Than this new incoming connection *must* follow a different path in the interaction with the opensll library. Already added new states like, ACCEPTING and CONNECTING, in stead of EXCHANGE however, testing it with a server build using the Thunder fnctionality still fails. It is probably due to the functionality/initialization that has to take place in the Initialize() method of the SecureScketPort where the SSL context is being created. The diffrentiation between a client socket and a server socket is already added to the Initialize, I guess it has to be tweaked. The client functionality of the SecureSocketPort has been tested with a server on the internet and is still working oke, so Client functionality has *not* been broken with these changes!
Closed
MFransen69
approved these changes
Nov 22, 2024
|
@pierre, per my understanding your assumption about server vs client is correct as already discussed with @MFransen69 . I am in the process of adding it as a sequel of #1794 though much of the changes there are as I interpret indeed related to the missing trigger for initialisation. I assume work continues here and the draft PR for review purpose (only) can be closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sofar Thunder supported SecureSocket clients where the intiative to enable secure connections was only based on creating a socket as a client. Tests are being written that require a secure socket server. This requires a sifferent set of calls and revealed an issue in the SocketPort.
The server accepts the incoming socket. The bug was that the incoming socket, as it is already open and connected would not call the "Initialize()" method before it was added to the Resource Monitor. This has been fixed in SocketPort.cpp.
Than this new incoming connection must follow a different path in the interaction with the
opensll library. Already added new states like, ACCEPTING and CONNECTING, in stead of EXCHANGE.
However, testing it with a server build using the Thunder functionality still fails. It is
probably due to the functionality/initialization that has to take place in the Initialize()
method of the SecureScketPort where the SSL context is being created. The differentiation
between a client socket and a server socket is already added to the Initialize, I guess it
has to be tweaked.
The client functionality of the SecureSocketPort has been tested with a server on the internet
and is still working oke, so Client functionality has not been broken with these changes!